chore: release 0.1.0 - #1

…artifact is pinned (#359)

Two follow-ups on `main` from the adversarial review of #357.

## 1. The rejection/dedup query is already saturated — silently

`gh pr list --limit N` is a window, not a ceiling: it returns the newest
N rows and drops the rest with no flag, no warning and no count. The
marker self-heal — the thing that makes a human's rejection survive a
body edit — was a plain `--state all --limit 200` whose state filter is
applied *client-side*, so every PR in the repo competed for those 200
slots and the merged ones won.

Measured live on this repo, 2026-08-05:

```
gh pr list --state all    --limit 200 -> 200 [MERGED=184 CLOSED=14 OPEN=2]  #125..#358
gh pr list --state closed --limit 200 -> 200 [MERGED=186 CLOSED=14]
gh pr list --state all    --limit 200 --search "is:unmerged"
                                      -> 28  [CLOSED=26 OPEN=2]             #1..#358
```

Two things the review did not have:

- **`--state closed` is not a fix.** gh maps it to CLOSED-**or**-MERGED
— 186 merged against 14 closed, just as full.
- **Twelve closed PRs are already invisible.** The repo has 26
unmerged-closed PRs; the current listing sees 14. The lost set is `#1,
30, 50, 56, 59, 61, 63, 94, 95, 96, 119, 120`, each confirmed CLOSED by
`gh pr view`. None is a drift PR, so no rejection is lost *today* — but
the mechanism is running now, and MERGED is the population that grows
daily.

**Fix.** Both self-heal listings additionally query `--search
"is:unmerged"` and union the two views. That excludes merged PRs
server-side: 200/200 slots consumed becomes 28/200, and 28 is the
*complete* unmerged population back to #1. `is:unmerged` is a STATE
predicate, so unlike `<key> in:body` it cannot be defeated by the very
body edit the self-heal repairs, and a just-closed PR matches under
either indexed state. The plain listing is unioned rather than replaced,
so the index-free view stays and plain entries win on collision.

Headroom is not a proof, so saturation is also made loud:
`assert_listing_complete` refuses any listing that comes back full at
its `--limit` rather than deciding on it. `--limit 200` also stopped
being a magic number — each step binds `PR_LIST_LIMIT` once and the
audit reads the same variable.

## 2. "the one unpinned executable in the job" was false

`89e5a07` pinned `ollama.com/install.sh`. That script then streams
`ollama.com/download/ollama-linux-<arch>.tar.zst` — mutable,
unversioned, no digest — through `zstd -d` into `sudo tar -x` under
`/usr/local`.

Run verbatim out of the pinned script's own bytes, with curl serving
attacker content:

```
STEP_EXIT=0
SUDO_RAN argv=tar -xf - -C ./dest
TAR_RAN  argv=-xf - -C ./dest
what tar was handed: ATTACKER-CONTROLLED TARBALL BYTES
```

A compromised tarball plants a root-owned `git`/`gh`/`node` on PATH
exactly as well as a compromised script would, and every later step
holds a `contents:write` + `pull-requests:write` app token those
binaries can reach.

It cannot be fixed in place — install.sh pipes the download straight
into `tar`, so it never holds the file and has nothing to verify;
`OLLAMA_VERSION` only appends `?version=`, a version pin rather than a
byte pin.

**Fix.** install.sh is not used. The release artifact is fetched from an
immutable release tag and sha256-checked before anything unpacks it.
Digest agreed by three independent sources: the v0.32.6 release's
`sha256sum.txt`, the GitHub release API's asset `digest` field, and
sha256 of the 1,420,686,963 downloaded bytes. Archive layout confirmed
by listing it (`bin/ollama` + `lib/ollama/*`, so `-C /usr/local` puts
the binary on PATH). Dropping install.sh also drops its NVIDIA CUDA repo
adds and `$PACKAGE_MANAGER -y install`; the step already ran `ollama
serve` itself rather than using its systemd unit.

The false claim is corrected in the workflow comment, the suite's header
comment, its describe name and its failure messages. Two further stale
claims about the self-heal listing `--state open` (false since #357) are
corrected too. The commit message that first asserted it is in history
and cannot be rewritten.

## Red-green

The `gh` stub could not previously express item 1's bug — it ignored
`--limit` and returned the whole population, so a saturated window
looked exactly like a healthy one. It now models what real gh does.

**RED (watched).** The existing rejection scenario plus 200 newer MERGED
PRs — both PR-open steps re-proposed the rejected changeset:

```
FAIL  a rejection is still found once MERGED PRs have filled the listing window
  stdio: Pushed branch main-1111222233334444 … Matched PR #56
FAIL  needs_human_pr: a rejection survives a full window there too
  stdio: Pushed needs-human branch … Opened needs-human PR #57
```

**GREEN.** 154 passed, exit 0.

**RE-BREAK (watched), each mutation restored and md5-verified:**

| mutation | tests red |
|---|---|
| neuter the union so unmerged rows are dropped | 2 |
| delete all four `assert_listing_complete` calls | 2 |
| raise the audit threshold out of reach | 1 |
| replace the tarball digest comparison with `if false` | 1 |
| point the fetch back at `ollama.com/install.sh` | 1 |

Item 2's guard now watches `tar`, not `sh`, and the positive control
asserts `tar` was handed exactly the verified bytes rather than merely
that it ran.

## Gates

`pnpm build` 0 · `pnpm test` 0 (**5048 passed / 171 files**) · `pnpm
test:drift` 0 · `tsc --noEmit` 0 · `pnpm lint` 0 · `pnpm test:exports` 0
· prettier clean · `actionlint` 0 · `zizmor` 0 findings · `bash -n` on
all 16 `run:` bodies 0 · commitlint 0.

## Not fixed here

`.github/workflows/test-drift.yml:177` does the same `sh install.sh`
with **no pin at all**, in a job holding five provider API keys, with
provisioning ahead of the steps that use them. Same defect, different
file — flagged, not touched.

…edup window

`gh pr list --limit N` is a window, not a ceiling: it returns the newest N rows
and drops the rest with no flag, no warning and no count. The self-heal listing
that makes a rejection survive a body edit was a plain `--state all --limit 200`
whose state filter is applied client-side, so every PR in the repo competed for
those 200 slots — and the merged ones, which no guard here consults, won.

Measured on this repo on 2026-08-05: that listing came back FULL, 184 of the 200
MERGED, reaching back only to CopilotKit#125. The repo had 26 unmerged-closed PRs and the
listing could see 14; twelve were ALREADY outside the window. A closed drift PR
aging out the same way does not make the step cautious, it makes it wrong — "no
closed PR carries this key" is what it reads, so it re-proposes a changeset a
human rejected, every morning, silently.

Both self-heal listings now additionally query `--search "is:unmerged"`, a state
predicate that excludes merged PRs server-side (28 rows, back to CopilotKit#1, on the same
measurement) and — unlike `<key> in:body` — cannot be defeated by the body edit
the self-heal exists to repair. The plain listing is unioned, not replaced, so
the index-free view stays. `--state closed` is not a substitute: gh maps it to
CLOSED-or-MERGED and returned 186 merged against 14 closed.

Headroom is not a proof, so every listing whose completeness a guard relies on is
now audited: one that comes back full is refused with an `::error::` rather than
decided on, because a truncated listing and a complete one are otherwise
indistinguishable.

Red-green: the `gh` stub now models `--limit` truncation the way real gh does
(newest-first, silent). Against the unfixed workflow both PR-open steps opened a
brand-new PR for a changeset a human had rejected; they now find it. Mutations
confirmed: neutering the union reds 2, deleting the audit calls reds 2, raising
the audit threshold out of reach reds 1.